Embodiments of the present invention relate to computer software, and more particularly relate to techniques for facilitating the testing of changes to the metadata of a metadata-driven software application.
In recent years, an increasing number of software applications are being built using a metadata-driven approach. These applications (referred to herein as metadata-driven applications) are structured such that aspects of their content, behavior, and/or appearance are specified via metadata rather than program code.
In the course of developing and/or maintaining a metadata-driven application, it is often necessary to make changes to the metadata of the application that affect the application's runtime behavior. The metadata may need to be patched, for example, to address various bugs, or to implement enhancements. These changes must typically be tested in a controlled fashion prior to incorporating them into the mainline version (i.e., most current, tested version) of the metadata used in a production environment.
According to one known approach, such testing is achieved by creating an independent staging environment based on the production environment, and applying the changes to the test version of the metadata used in the staging environment. The application running in the staging environment is then made available to one or more users for testing purposes. In this manner, users of the application running in the production environment are shielded from any potential issues/bugs introduced by the changes. Once the changes are validated in the staging environment, the changes are applied to the mainline version of the metadata used in the production environment. This typically involves bringing the production environment offline, patching the mainline version, and then bringing the production environment back online.
While the above approach is functional, it is also problematic for several reasons. First, creating and maintaining an independent staging environment is resource-intensive and cumbersome. For example, the staging environment will typically require its own application server and data repository, and will need to be configured separately from the production environment to enable user access for testing. Second, as discussed above, the production environment must generally be brought offline prior to applying any metadata changes. This process undesirably increases the downtime of the environment, resulting in operational inefficiencies and delays. Third, a single staging environment cannot support situations where multiple (possibly incompatible) sets of metadata changes need to be tested simultaneously.